CoCoPySHS : La traduction de R vers Python : enjeux pratiques et épistémiques

  • Célya Gruson-Daniel (Inno3, COSTECH/UTC)
  • Claire Lemercier (CNRS, CSO/SciencesPo)
  • Emilien Schultz (Medialab/SciencesPo)

:date: 1er juin 2023 de 13h à 14h inscription

Introduction : contexte et objectifs

Contexte : retour sur Décliner-SO

  • Décliner la science ouverte : mission réussir l’appropriation de la science ouverte (CoSO) https://declinerso.pubpub.org/
  • Groupe de travail multidisciplinaire, usage de méthodes mixtes
  • Travail commun sur le questionnaire “données et science ouverte” Claire et Célya
  • Suite avec Emilien pour tester la reproducibilité des résultats

But de la présentation

  • Retour d'expérience : faire part du travail commun réalisé
    • sur l’analyse du questionnaire et de sa reproductibilité,
    • des questions qui se sont posées au fur et à mesure
    • des aspérités/frictions rencontrées du passage de R vers Python
  • Constats engager une réflexion sur le bagage implicite épistémo, technique qui est présent dans le code et quelques pistes de bonnes pratiques conscientisation possible (pour soi et pour les autres)

Retours d’expérience

Présentation du travail de Claire de Calc vers R (1/2)

  • des questions auxquelles on veut répondre,

    • par ex : qui emploie quels mots pour parler des données ? qui réutilise des données ?
  • mais beaucoup d’exploration aussi

    • volonté de démontrer la diversité et l’ordonner
  • objectifs : savoir ce que disent nos données, en discuter avec Célya, rendre les résultats montrables (rigueur quanti/public qualit)

Présentation du travail de Claire de Calc vers R (2/2)

  • recodages initiaux sous Calc pour “sentir” les données -> difficulté/intérêt à les expliciter ensuite
  • utilisation de bibliothèques et communautés R déjà connues (FactoMineR, explor, questionr) ou non (survey, gtsummary)
  • explorations/résultats “négatifs” non repris dans la version reproductible (ex : choix des variables actives/supplémentaires)
  • routines personnelles (fonction catdes)

Présentation du travail d’Émilien de R vers Python (1/2)

  • travail de retro-engineering pour expliciter des choix implicites
  • besoin de traduire complètement des fonctions non natives de Python FactoMineR et catdes
    • recherche poussée pour comprendre choix stat qui ont été faits (test de Kramer vs. test hypergéométrique)
    • aide de la communauté en ligne (Github, Twitter, etc.)

Présentation du travail d’Émilien de R vers Python (2/2)

  • temps de travail non négligeable pour arriver à une reproducibilité des résultats en passant d’une langue à l’autre
  • effort de documentation pour mettre en avant toutes ces frictions

Constats

Langage et communautés épistémiques et de pratiques (1/2)

  • Le passage de R vers Python a rendu visible un ensemble de choix méthodologiques, épistémo (souvent inconscients) qui n’apparaissent que dans cette comparaison R/Python
    • par ex. pour les analyses statistiques multivariées, “tradition” ACM HCPC dans R peu ou pas développée dans Python. [communauté très localisée dans R aussi, en plus !]

Langage et communautés épistémiques et de pratiques (2/2)

  • L’utilisation d’un langage plutôt qu’un autre est associé à des usages, des pratiques reliés à des communautés disciplinaires et épistémo, ce qui orientent les analyses menées
    • notion en STS de mondes sociaux et d’épistémologies locales (présentes au sein déjà d’un langage et encore plus entre langage) cf. Dagiral/Parisie
    • un micro-monde : d’un tutoriel pour historiennes à FactoMineR/Shiny : d’une niche au sein de R à une transposition complexe dans Python `
    • R puis Python, tributaires de tradi/uctions plus anciennes : ici, SPAD `

Langage et évolution des usages (1/2)

  • Prise de conscience des fonctions développées en fonction des usages.
    • Plus ou moins de documentation en fonction de la popularité.
    • Question du passage d’une langue à l’autre, pas aisée pour une communauté, temps d’apprentissage et dettes d’usage

Langage et évolution des usages (2/2)

  • Le passage d’un langage à l’autre a un coût non neutre et nécessite de replonger dans des choix techniques/statistiques faits
    • des philosophies sous-jacentes dépendant des communautés impliquées dans le langage
    • un entremêlement entre les notions conceptuelles et l’opérationnalisation : comment mieux identifier les deux ?

Bonnes pratiques

Faciliter le dialogue R et Python dans une logique de reproducibilité (1/2)

  • La documentation est majeure pour détailler les algorithmes
  • Maintenir une vigilance sur les fonctions importées qui embarquent non pas seulement du code, mais tout un bagage épistémo invisibilisé

Faciliter le dialogue R et Python dans une logique de reproducibilité (2/2)

  • Il serait intéressant d’indiquer les fonctions “langage dépendant” et celles “langage reproductible” / un index des équivalences (et des trous dans la raquette)
  • Articuler les avantages des deux langages : dynamique en cours de multiples manières

Partager : Citations et littératie

  • Une bonne pratique serait la citation des articles de référence en lien avec des fonctions employées, car c’est un choix méthodologique (et une reconnaissance des auteur·es !)
  • Aujourd’hui, peu de littérature qui crée des ponts entre R et Python. Développer une littératie à ce sujet

Enjeux de formation

  • Pour des soucis de formation et d’accessibilité de ces enjeux, faut-il imaginer des codes plus verbeux, mais plus compréhensibles ?
  • Aujourd’hui, une nécessité de créer des espaces d’échanges d’aide au sujet de ces traductions ?
    • repérer les effets de leviers possibles (via dynamique d’enseignement, conférence France International ? ) exemple en histoire : https://programminghistorian.org/

Ressources

Brouillon Notes Célya

  • but de la présentation

    • continuer à plonger dans la fabrique des données et des résultats de recherche en montrant l’implication des dispositifs/interfaces sur les données obtenues.
    • montrer que chaque dispositif et interface associés embarque un ensemble de choix techniques, épistémologiques qui tendent à être invisibilisés.
  • Avec l’essai de reproductibilité du questionnaire “Décliner-SO”, on se rend compte que :

    • la documentation des processus est majeure pour expliquer les choix faits à un moment t.
    • Certains choix peuvent ne pas être documentés ou faits de manière non automatique dans une optique d’exploration (tout refaire demande un temps conséquent et pose la question du temps passé au démarche de reproductibilité et de science ouverte et de sa valorisation)
    • l’utilisation d’un langage de programmation plutôt qu’un autre a des conséquences sur les possibilités offertes : choix de bibliothèques développées dans une communauté pour des usages précis( (par ex FactoMineR que l’on ne retrouve pas dans une autre communauté), l’adaptation a un coût et remet en évidence des choix statistiques implicites faits dans une culture de recherche donnée.
      • Ici le cas a été celui de FactoMineR et de catdes (recodé sous python) après une recherche poussée nécessaire pour comprendre que le v test correspondant n’était pas un test de Kramer mais un test hypergéométrique
    • les usages vont influencer les développements et la qualité de la documentation des bibliothèques. Par exemple pour des fonctions très utilisées de FactoMineR celles-ci sont bien documentées mais d’autres pas du tout. (CL : et les auteurs ont sans doute davantage intérêt à documenter ce qui va leur attirer de nouveaux utilisateurs “naïfs” plutôt que ce qui va servir “seulement” à porter leur bonne idée vers un autre langage…)
    • le passage d’un langage à l’autre n’est pas aisé et nécessite d’avoir un changement de pratique de la communauté dans son emsemble mais souvent il y a une dette d’usage et un poids d’apprentissage qui fait que le passage ne va pas être aisé.
  • Que faire dans l’optique de rapprochement/articulation entre R et python en SHS ?

    • voir où sont les motivations/intérêt face à des problèmes récurrents (non résolus dans une communauté), le passage à un autre langage peut ouvrir des portes. Question des effets de leviers possibles, des points de bascule ?
    • s’appuyer non pas que sur des dynamiques françaises, mais aussi internationales
    • voir quelles sont les opportunités d’un langage, d’un autre et les dynamiques des communautés
    • penser la soutenabilité des bibliothèques entre une démarche collaborative à la scikitlearn (qui est organisé et financé) et des projets unipersonnels de code dont le maintien du package dépend d’une personne : revient aux thématiques actuelles clefs au sein des logiciels libres et open source sur la maintenance des projets logiciels.

Note Claire qui ne sait pas où la mettre

  • dans le cas qui nous occupe, on a aussi d’autres passifs à prendre en compte : R est encore en train de finir de s’imposer en socio quanti en France (bcp de collègues ont déjà dû faire la traduction depuis SAS, SPSS, Stata ou SPAD vers R) et en histoire, aucune culture de ligne de commande du tout (et grande peur en la matière) -> psychologiquement, peut-être plus dur pour certain·es collègues de se dire qu’il faudrait apprendre Python aussi. Alors qu’en fait apprendre les bases des deux en parallèle pourrait avoir un sens et marcher ! (la note d’espoir…) cf. un parallèle peut-être trop éloigné sur le plurilinguisme : https://journals.openedition.org/rdlc/9208

Notes Emilien

  • Les outils convergent entre les communautés R et Python (Posit, Jupyter) avec la question qui se pose de produire certains codes en bilingue de manière systématiques
  • dans quelle mesure un traitement possible que dans un langage est-il reproductible ? Comment signaler le fait qu’une opération est langage dépendant et qu’une autre est correctement reproductible entre deux langages
  • la question de l’héritage est importante : certaines fonctions sont natives d’un langage, d’autres sont des traductions de fonctions déjà existantes. Comment le faire apparaitre ? Faut-il le faire apparaitre ?
  • Il existe encore peu de littérature qui participe à créer des ponts (mis à part https://www.oreilly.com/library/view/python-and-r/9781492093398/ à ma connaissance). Faut-il mieux rendre visible cette littérature
  • Il existe des paradigmes implicites dans les langages qui ne deviennent visibles que par comparaison avec d’autres manières de faire
  • Certaines pratiques qui sont initialement associées à un langage (par ex. les notebooks python) ne sont pas intrinsèques au langage, ce qui pose la question des arguments “substantiels”
  • le fait de devoir recoder une fonction compliquée est un véritable frein à entreprendre un projet : comment identifier au plus tôt ce genre de frein ?
    ((CL : en l’occurrence n’aurait-on pas pu décider d’employer un test différent et expliciter que cela peut créer de légères différences dans la reproduction des résultats ? (question peut-être hors de propos) -> pose la question de ce qui est important dans catdes : pour moi le test ne l’est pas, peut-être que pour ses créateurs si))
  • comment bien documenter des fonctions scientifiques, notamment en lien avec la littérature existante. Faut-il systématiquement citer dans la documentation les références scientifiques ? Faut-il essayer de garder une lisibilité explicite de la notation de l’article de référence ?
  • est-ce qu’il y a un enjeu pour certains traitements (HCPC, catdes) de forcer un code plus verbeux, car il faut le rendre accessible à tous
  • cette petite mission a été le support à une traduction de code : comment mettre en avant dans les projets/activités ces opérations pour les valoriser en tant que telle ?
  • quels sont les espaces existants pour justement demander de l’aide à la traduction ? Dans mon cas, j’ai trouvé sur Twitter un statisticien qui m’a aidé, et françois husson le concepteur de la focntion a répondu à mon mail. ((CL ça me semble typique comme expérience ! donc intéressant à citer))

to do :

  • à voir pour référence biblio à ajouter (STS, socio, SIC) Bigot, Mabi, Denis ?
  • sur partie soutenabilité des logiciels libres : travail en cours au sein d’inno3

resssource : Erice dagiral https://www.college-de-france.fr/media/sociologie-travail-createur/UPL445036226293291601_Menger_Paye_Big_data_Livre_entier_2017.pdf